Subject: Network Management Working Session Meeting Report

From: "Michael O. Allen (919-254-4442)" <[email-masked]>
Date: Thu, 24 Feb 94 10:53:51 EST

Here is a summary of the working session last week in Anaheim.

Mike
......................................................................

        Network Management Working Session Meeting Report

A working session on several APPN network management topics was held
2/17/94 at the APPN Implementers Workshop in Anaheim.  Mike Allen, IBM
Networking Systems, chaired the session.  Approximately 30 people
attended.  Softcopy of the charts presented are available via anonymous
FTP from "ibmstandards.cary.ibm.com".  The file is "aiw4chrt.txt" under
directory "aiw/snasnmp".

The topics discussed at the session were:

   1.  Recently announced NetView V2R4 APPNTAM feature

   2.  Status of the IBM APPN Node MIB

   3.  Including SNA/MS alert information in SNMP traps

   4.  Overview of the IETF NAU MIB

   5.  Possible application of the NAU MIB to Dependent LU Requester

   6.  APPC MIB Working Group Report

   7.  SNA DLC MIB Working Group Report

Here is a summary of the discussion on each topic:

1.  Recently announced NetView V2R4 APPNTAM feature

In the AIW session immediately preceding ours, Louise Herndon Wells,
from Interwork Technology Institute, gave a report on the status of
APPN products across the industry.  One of the topics she reported on
was the recent availability of the APPNTAM feature of NetView, so I
took a few minutes at the beginning of the session to explain what
APPNTAM was.  It is a set of NetView applications that provide
graphical displays of APPN topology and collect accounting statistics
on LU-LU sessions.  The applications are based upon the OSI CMIP
protocol transported over SNA/MS.  A CMIP agent for APPN that runs on
OS/2 Communications Manager is shipped with the APPNTAM feature.  A
CMIP agent for the VTAM product is reportedly also under development,
although no announcement has yet been made about availability.

A question was asked about availability of the GDMO specifications for
the CMIP support in APPNTAM.  Those specifications have been published
in the following IBM publications:

  IBM SystemView Mapping of OSI Upper Layers to MDS for CMIP over
  SNA (SC71-7137)

  IBM SystemView Managed Resource Model Reference and Templates,
  Volume 1:  Generic Definitions   (SC71-7138)

  IBM SystemView Managed Resource Model Reference and Templates,
  Volume 2:  APPN and SNA Subarea Management  (SC71-7139)

On-line versions of these books are also included in the February 1994
update of the CDROM "The Best of APPC, APPN, and CPI-C" (SK2T-2013-02).
In addition, the following publications may also be of interest:

  NetView APPNTAM Feature Implementation Guide (SC31-7050)

  NetView APPNTAM Feature Topology Data Model Reference (SC31-7051)

  NetView APPNTAM Agent Implementation Guide (SC31-7129)

The question then came up about the relationship of the SNMP management
activities going on at AIW with the CMIP support in NetView.  The
answer was that IBM recognizes the importance of SNMP management in the
networking products marketplace, especially in the US, so we are
working on SNMP management in a number of IBM products.  At the same
time, there are market segments, particularly in Europe and the US
telcos, that are looking for CMIP management products.  To provide
integration of SNMP-managed products into the APPNTAM application on
NetView, IBM is investigating a CMIP-SNMP proxy approach.  A prototype
has been developed and was described this week at an IEEE conference on
network management technology in Orlando.  Availability of a product
based upon this prototype has not yet been announced.

2.  Status of the IBM APPN Node MIB

The IBM 6611 APPN node MIB has been submitted to the RFC editor of IETF
requesting the status of informational RFC.  Progress of the IETF
submission will be reported on mailing list
"[email-masked]".  This document reflects exactly
the level of the MIB implemented in IBM's licensed network node code
package.  The version previously made available at AIW was slightly
downlevel.  The current level adds a DLC trace table to the previously
published MIB.  Softcopy of the RFC submission is available via
anonymous FTP from "ibmstandards.cary.ibm.com".  The file is
"appnmib.txt-02" under directory "aiw/snasnmp".  the older version is
still available under the same directory as "appnmib.txt".  Please
direct questions or comments on this MIB to the mailing list
"[email-masked]".

3.  Including SNA/MS alert information in SNMP traps

At the meeting, I handed out copies of a draft document that describes
a method for including SNA/MS alert information in an SNMP trap.  This
mechanism is supported by NetView/6000 V2, which will create an alert
from the objects in one of these traps and then forward the alert to
NetView/390.  Display of these traps at NV/6000 is done in the normal
way (customization is needed to display embedded alert information).

The document distributed at the meeting contains explanatory text and a
MIB representing the alert information.  It will submitted to IETF in
the near future as an informational RFC.  The draft document "Inclusion
of SNA/MS Alert information in Traps" is available via anonymous FTP
from "ibmstandards.cary.ibm.com".  File is "rfcalert.txt" under
directory "aiw/snasnmp".  Please direct any questions or comments to
the author, Bob Moore, IBM Networking Systems Architecture
([email-masked]).

4.  Overview of the IETF NAU MIB

I gave a brief overview of the NAU MIB, explaining its structure and
expandability, and how it can be applied to the management of an SNA
product implementing PU 1 or 2.  The rationale for the staging of the
NAU MIB work in the working group was explained as well.  Copies of the
MIB document were distributed.

Jim Fletcher, from IBM, asked how the table indexing mechanism used to
associate LUs with their PUs would work in a node that provides
multiple links into the subarea boundary.  Some products have been
built that use multiple links to provide greater bandwidth for boundary
connections, but each one of these links must support a different PU
name.  A single LU will appear to be supported by a different PU
depending upon which link is of interest.  It appears that this
configuration cannot be completely modeled by the current table
indexing structure, since each LU can be associated with only one PU at
a time.  Investigation is needed to determine if this restriction is
acceptable, or if we need to find a way to address it.

5.  Possible application of the NAU MIB to Dependent LU Requester

The dependent LU requester architecture provides a migration path for
existing SNA/MS management of PU resources from an SSCP.  All the
current NetView applications for management of PU resources will
continue to work as they do now on a system with the dependent LU
server function.  However, for SNMP-managed APPN nodes, a MIB is needed
to represent the PUs and LUs supported by DLUR.

I presented a proposal for applying the NAU MIB to this requirement.
Basically, the idea is for an APPN node to include the DLUR-supported
resources (links, PUs, LUs, and sessions) in the NAU MIB tables at the
APPN node itself.  The subagent would show the APPN node as the first
entry in the snaNode*Table ("*"= Admin+Oper), with entries for the
supported PUs following in the table.  The information in the
snaNode*Table would be supplemented minimally with the name of the DLUS
(netid.cpname of the DLUS node) associated with each PU.  The most
appropriate location for this supplementary information MIB-wise is yet
to be determined.  The snaLu*Table would have an entry for each LU
supported directly by the APPN node, as well as an entry for each
dependent LU supported via DLUR.  Likewise, the snaLuSessnTable would
contain entries for the sessions of the independent LUs as well as the
sessions of the dependent LUs supported via DLUR.

The suggestion was made that the status of the DLUR-DLUS server
sessions is important to managing the DLUR function, and it probably
should be maintained in a separate table.  The DLUR-DLUS sessions are
ordinary APPC sessions, so they will show up in the snaLuSesssnTable as
a matter of course, but there is likely to be some unique information
that we will need to maintain about the control traffic over the server
session.

In general, there seemed to be a consensus that using the NAU MIB for
DLUR was a good direction, and we should continue to work on it.  After
the session, I met with Ed Tremblay, the chair of the DLUR SIG, to
discuss how this work should be coordinated with his SIG.  He
recommended that this MIB effort be considered part of the DLUR SIG
with no further administrative overhead.  This approach was accepted by
the plenary session when I reported on our meeting.  A draft DLUR MIB
will be distributed by the June AIW.

6.  APPC MIB Working Group Report

I reported on the revised charter and schedule of the NAU MIB working
group, which has begun working on extensions to support T2.1 nodes and
APPC.  Since the working group is planning on having an initial draft
distributed before the IETF meeting at the end of March, there is a
call for submissions of private APPC MIBs through the end of February.
I described some the information that is potentially needed for APPC,
and got some suggestions for further investigation.  The list of
possible information includes:

  *  Partner LUs
  *  Modes
  *  TPs
  *  APPC-unique session characteristics
  *  Conversations
  *  Security options and characteristics

Interested parties were encouraged to join the NAU MIB mailing list in
order to better keep up with developments.  The APPC MIB working group
will hold regular meetings at the AIW as well as the IETF, so companies
who do not attend IETF can still participate.

7.  SNA DLC MIB Working Group Report

Shannon Nix from Netlink, who is the chair of the SNA DLC MIB working
group at IETF, gave a report on his group's progress.  Their initial
deliverable, the SDLC MIB is now complete, and they are beginning to
focus on their next task, an LLC MIB.  They are looking at IEEE efforts
in this area, and they are also asking for submissions of any private
MIBs that companies would like to share.  Their mailing list is
"[email-masked]".